I noticed that my "Items with option flags" search didn't show the right number of tracks, and when I went to investigate, I discovered that lots of my playlists had "options = 0x0".

Firstly, and most seriously, the correct format for these values is AFAIK 2 hexits without the leading 0x, i.e. 00 in this case.

Secondly, I think jEmplode incorrectly reads the options value from the player, meaning that many of my playlists have lost their options completely. For instance, I marked my top-level Books playlist using Emptool as "Ignore as child" so that a shuffled down-down-down wouldn't include random chapters of books.

Thirdly, even options that I set using jEmplode seem to have reverted to 0x0 - not necessarily jEmplode's fault though, as I use Emptool for uploading tunes.

I know that Mike is re-working some of the internals of jEmplode, but not sure whether he's aware of this issue. I hope it can be fixed during the rework.

Please state which version of Jemplode caused this problem for you?

I'm not sure which version(s) of jEmplode have this problem. I'm pretty sure it didn't happen before v32, and I've not taken it beyond v40. I'm currently using v39.

Doing another search, I find that options I added with jEmplode appear, but with 0x prepended. For some reason, I don't getting new results with an advanced search for options!="", but options like 0 works. This is why I thought my options had disappeared - my saved custom search (options > "0") stopped returning most of them, but they remained with the prefix added. Or perhaps not - the only ones that begin with 0x are ones I've set using jEmplode - I believe that I've lost options from tunes and playlists that I've touched with jEmplode.

Some tunes have "0x0" - since this is the default, no "options" tag might be appropriate here?

When I first added options, using Emptool, I found that they didn't work with the 0x prefix present. Having tried again, with beta13, I'm no longer sure. jEmplode doesn't seem to be reading my old values, but the new ones do appear to be working. So my original report seems to be a bit premature.

So what's the final analysis on this one? Did this turn out to be a bug? Incidentally i did a bunch of fixes to the advanced search parser -- that was the first piece of code that I setup automated test cases for ... I'll try that particular search when I get home from Atlantic City (woohoo!) on Sunday.

ms

The summary is

• AFAICT, the newest player software will accept values with or without the 0x prefix. Can someone confirm that this is supposed to be the case?
• If jEmplode reads a value without the prefix, it changes it to 0x0. I don't think it should. I think this happens whenever any tags of the node in question are edited (not just when the options are changed).

AFAICT, the newest player software will accept values with or without the 0x prefix. Can someone confirm that this is supposed to be the case?

Yes, it is. The 0x form is preferred though. Having "options" default to hex and all the other numeric fields default to decimal is a bit of a wart IMO but we can't change it now, not with thousands of players full of thousands of files all without the 0x on their options tags.

If jEmplode reads a value without the prefix, it changes it to 0x0. I don't think it should.

Except possibly for 0, I'd recommend that jEmplode writes all values with the 0x prefix.

Peter

I wrote:

> If jEmplode reads a value without the prefix, it changes it to 0x0. I don't think it should.

To clarify, I don't mean that I think it shouldn't add the 0x prefix - I mean that it shouldn't change the value to zero if it wasn't already zero.

OK .. the new version is basically what Peter described now:

1) If your tag starts with 0x, it will be read as hex
2) Otherwise it will try to read it as a decimal number
3) If that fails, it will turn into 0
4) Whenever it writes back out, it writes as 0xXXX

Mike

Groovy.

1) If your tag starts with 0x, it will be read as hex
2) Otherwise it will try to read it as a decimal number
3) If that fails, it will turn into 0
4) Whenever it writes back out, it writes as 0xXXX

What I meant to imply, is that (very) old versions of Emplode wrote the options field as hex without the 0x. Modern versions write it as hex with the 0x.

The code in the player uses strtol, with a default base of 16 for the options tag and 0 for all other tags. So stage (2) should read "Otherwise it will try to read the value as a hex number (if it's the options field) or a decimal number (all other fields)".

As I said, it's a wart. Sorry about that.

Peter

Ah hah .. good to know That would have been a pain to debug if I had left it my way...

Thanks
Mike